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ABSTRACT 


As  digital  control  systems  are  used  in  life-critical  applications,  assessment  of  the 
safety  of  these  control  systems  becomes  increasingly  important.  One  means  of  formally 
performing  this  assessment  is  through  fault  tree  analysis.  Software  Fault  Tree  Analysis 
(SFTA)  starts  with  a  system-level  hazard  that  must  be  decomposed  in  a  largely-human- 

intensive  manner  until  specific  modules  of  the  software  system  are  indicated.  These 

I 

modules  can  then  be  formally  analyzed  using  statement  templates. 

The  focus  of  this  thesis  is  to  approach  the  decomposition  of  a  system-level 
hazard  from  a  formalized  standpoint.  Decomposition  primarily  proceeds  along  two 
distinct  but  interdependent  dimensions,  specificity  of  event  and  subsystem  size.  The 
Specificity-of-Event  dimension  breaks  abstract  or  combined  events  into  the  specific 
system  events  that  must  be  analyzed  by  the  fault  tree.  The  Subsystem-Size  dimension 
deals  with  the  scope  of  the  hazard,  and  itemizes  the  subsystems  where  localized  events 
may  lead  to  the  hazard.  Decomposition  templates  are  developed  in  this  thesis  to 
provide  a  framework  for  decomposing  a  system-level  hazard  to  the  point  at  which  line- 
by-line  code  analysis  can  be  conducted  with  existing  statement  templates.  These 
templates  serve  as  guides  for  conducting  the  decomposition,  and  ensure  that  as  many  as 
possible  of  all  the  applicable  decomposition  aspects  are  evaluated. 
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I.  INTRODUCTION 


A.  BACKGROUND 

A  fault  tree  is  a  graphical  representation  of  an  analysis  of  a  physical  system. 
This  analysis  shows  whether  a  combination  of  one  or  more  contributing  causes  can 
result  in  the  occurrence  of  a  specific  undesired  event.  The  starting  point  for  the 
construction  of  a  fault  tree  is  the  specification  of  an  undesired  event.  Fault  tree 
analysis  has  been  applied  to  both  the  hardware  and  software  of  systems  as  a  means  of 
proving  an  undesired  event.  The  principles  that  are  used  to  analyze  software  and 
hardware  via  fault  trees  are  sufficiently  different  to  consider  hardware  and  software 
fault  tree  analysis  as  two  separate  processes. 

1.  Hardware  Fault  Tree  Analysis 

Fault  tree  analysis  was  first  applied  to  hardware  systems,  and  made 
extensive  use  of  hardware  component  failure  rates.  With  hardware,  the  probability  of  a 
specific  piece  of  hardware  failing  due  to  wear  can  be  accurately  determined.  Either  the 
analysis  of  historical  data  or  direct  experimentation  can  be  used  to  assign  a  probability 
of  failure  to  virtually  any  piece  of  hardware.  Logic  theory  in  combination  with 
probability  of  failure  data  forms  the  mathematical  basis  for  fault  tree  analysis. 
a.  Logical  Relationship  Between  Hardware  Events 

The  symbols  used  to  build  the  fault  trees  presented  throughout  this 
thesis  are  shown  in  Figure  1.  These  symbols  are  a  subset  of  the  symbols  presented  by 
Hammer  [Ref.  l:pp.  227-229]  that  are  commonly  used  in  both  hardware  and  software 
fault  tree  analysis.  Bagchi  [Ref.  2:p.  4486]  shows  how  two  basic  logic  properties,  OR 
and  AND  can  be  used  to  relate  the  probabilities  of  independent  events.  Consider,  for 
example,  the  following  two  equations  where  A,  B,  C  are  independent  events  and  P(A), 


1 


The  RECTANGLE  indicates  an  event  to  tie 
analyzed  further 


The  DIAMOND  is  used  for  non-pr imal  events 
not  developed  further  for  lack  of  information 
or  insufficient  consequences 

The  OVAL  is  used  to  indicate  a  condition 

The  AND  gate  indicates  that  all  input  events 
are  required  in  order  to  cause  the  output 
event 

The  OR  gate  indicates  that  one  or  more  of 
the  input  events  are  required  in  order  to 
cause  the  output  event 


The  NOT  gate  indicates  that  the  output  event 
is  the  logical  negation  of  the  input  event 


Figure  1.  Relevant  Fault  Tree  Symbols 

P(B),  P(C)  are  equal  to  the  probability  of  the  occurrence  of  the  events  A,  B,  C 
respectively.  For  the  purposes  of  demonstrating  the  logical  AND  and  OR  properties, 
let  Equation  (1)  be,  "if  C=A+B  then  P(C)=P(A)+P(B)-P(AAB)\  and  let  Equation  (2)  be, 
"if  C=A*B  then  P(C)=P(A)*P(B)".  In  both  Equation  (1)  and  Equation  (2),  P(X)  is  the 
probability  of  independent  event  X  occurring.  Equation  (1)  can  be  reduced  to 
P(C)=P(A)+P(B),  since  the  purpose  of  subtracting  the  probability  of  the  intersection  of 
two  events  is  to  remove  the  redundancy  involved  when  two  OR’d  events  occur 
simultaneously.  With  respect  to  fault  tree  analysis,  this  subtraction  is  not  strictly 
necessary.  If  two  OR’d  events  occur  simultaneously,  the  resultant  event  holds  just  as  if 
either  one  of  the  OR’d  events  had  occurred  separately,  and  in  many  systems  the 
probability  of  two  simultaneous  component  failures  is  sufficiently  low  as  to  be 
negligible. 
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Equations  (1)  and  (2)  form  the  basic  foundation  of  the  graphical 
depiction  of  a  fault  tree,  although  any  logical  relation  (XOR,  NAND,  NOR,  etc.)  can 
be  used  as  required  to  correctly  represent  the  system.  Bagchi  represents  the  logical  OR 
of  Equation  (1)  and  the  logical  AND  of  Equation  (2)  graphically  in  Figure  2. 


Figure  2.  Logical  OR  and  Logical  AND 


The  OR  gate  of  Figure  2  shows  the  resultant  fault  tree  from  a  system 

that  has  two  components  in  series.  A  failure  causing  either  event  A  or  event  B  will 

result  in  the  event  C.  The  AND  gate  of  Figure  2  shows  the  fault  tree  from  a  system 

that  has  two  parallel  events.  As  indicated  by  the  AND  gate,  both  events  A  and  B  must 

occur  in  order  for  event  C  to  result.  [Ref.  2:p.  4486]  In  short,  fault  tree  analysis  can 
be  used  to  identify  combinations  of  events  (hardware  failure,  design  flaws)  that  have 
the  potential  of  causing  the  occurrence  of  the  specified  undesired  event. 
b.  Orders  of  Fault  Events 

An  important  aspect  of  the  use  of  fault  tree  analysis  is  the 
decomposition  of  an  undesired  event  into  sub-events.  These  sub-events  must  be  further 
decomposed  until  system  components  or  actions  are  identified.  If  these  system  events 
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can  be  proven  to  be  incapable  of  occurring,  the  system  is  proven  incapable  of 
generating  the  undesired  event 

Fussell  developed  a  methodology  called  the  Synthetic  Tree  Model 
(STM)  [Ref.  3:p.  425]  that  distinguishes  between  four  orders  of  fault  events  to  guide  in 
the  decomposition  of  an  undesired  event  The  orders  represent  various  degrees  of 
abstraction  from  the  actual  system  components.  The  lowest  order  event,  first  order,  is 
the  most  abstract.  The  undesired  event  that  the  fault  tree  is  attempting  to  prove  or 
disprove  is  the  first  order  event  that  serves  as  the  starting  point  or  "root"  of  the 
analysis  tree. 

Consider  as  an  example  the  simple  electrical  circuit  in  Figure  3,  similar 
to  the  circuit  presented  by  Salem  [Ref.  4:p.  54]  in  his  work  on  fault  tree  construction. 
For  the  purpose  of  presenting  Fussell’ s  orders  of  fault  events,  this  example  circuit  is 


Figure  3.  Simple  Electrical  Circuit 

composed  of  a  light  bulb,  a  power  supply  and  a  switch  for  turning  the  light  on  and  off. 
The  undesired  event  that  might  be  used  as  a  first  order  event  could  be  the  event  "light 
not  on".  With  Fussell’s  methodology,  the  fault  tree  is  constructed  by  manually 
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decomposing  the  first  order  event  into  higher  order  (less  abstract)  events.  The 
undesired  event  "light  not  on"  could  be  broken  down  into  the  less  abstract  events  "no 
power  to  light  bulb"  or  "light  bulb  broken". 

Second  order  fault  events  are  conditions  that  effect  a  grouping  of 
components  that  if  failed  would  result  in  the  occurrence  of  the  first  order  event.  A 
second  order  event  for  our  example  circuit  could  be  "no  power  in  group  A",  where 
group  A  consists  of  all  components  effected  by  this  second  order  event.  In  our 
example,  group  A  would  be  comprised  of  the  power  supply,  light  bulb  and  light  switch. 
These  components  are  grouped  with  respect  to  the  serial  nature  of  electronic  circuits,  in 
that  the  failure  of  any  one  component  would  necessarily  result  in  the  apparent  failure  of 
all  the  other  components  in  the  group. 

A  third  order  event  involves  a  fully  functional  component  that  merely 
acts  failed  due  to  a  failure  in  another  part  of  the  system.  The  "no  power  to  light  bulb" 
event  decomposed  from  the  original  undesired  event  is  an  example  of  a  third  order 
event.  The  light  bulb  will  act  failed  (not  light  up)  when  in  fact  the  light  bulb  is 
functional  but  has  no  power  coming  into  it.  To  develop  this  third  order  event,  STM 
requires  a  search  for  all  second  order  groups  in  which  the  light  bulb  appears.  The  "no 
power  to  light  bulb"  event  requires  "no  power"  in  each  of  these  second  order  groups 
involving  light  bulbs.  In  other  words,  these  groups  are  AND’d  together  to  yield  the 
third  order  event  "no  power  in  light  bulb".  Thus,  a  third  order  event  is  comprised  of  a 
combination  of  applicable  second  order  events. 

The  final  level  in  Fussell’s  methodology  is  the  fourth  order  event.  A 
fourth  order  event  involves  a  component  that  acts  failed  due  to  the  input  that  the 
component  receives.  The  light  switch  being  in  the  off  position  would  be  an  example 
of  an  input  that  causes  the  light  bulb  to  act  as  though  it  had  failed. 
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The  development  of  Fussell’s  methodology  was  based  on  electronic 
circuit  principles.  Second  order  events  make  use  of  the  serial  path  of  an  electrical 
current.  This  reliance  on  the  serial  nature  of  components  in  an  electrical  system  is  a 
critical  aspect  of  Fussell’s  STM  methodology.  It  is  this  serial  nature  that  requires  the 
grouping  of  all  the  components  that  will  also  fail  if  any  component  along  the  electrical 
path  fails.  This  serial  grouping  forms  the  basis  for  linking  a  third  order  event  by  an 
AND  of  a  group  of  second  order  events.  This  serial  grouping  allows  Fussell’s 
methodology  to  require  that  all  groups  containing  a  component  failure  that  would  yield 
the  third  order  event  be  included  in  the  AND. 

Fussell  acknowledges  that  the  fault  trees  constructed  using  his  Synthetic 
Tree  Model  are  quite  lengthy.  The  length  of  his  trees  is  attributable  to  the  method  by 
which  Fussell’s  methodology  groups  second  order  events.  Second  order  events  require 
the  grouping  of  all  components  serially  connected  to  a  component  whose  failure  would 
result  in  the  second  order  event.  This  lengthens  the  tree  by  adding  on  components  that 
a  fault  tree  developed  using  Fussell’s  methodology  must  check.  A  tree  being  developed 
by  a  method  other  than  Fussell’s  might  not  require  this  type  of  grouping,  and  might 
therefore  have  less  branches  to  check.  There  is,  however,  an  advantage  attributable  to 
the  length  of  Fussell’s  trees.  Any  number  of  fault  trees  constructed  independently  for 
the  same  system  and  main  failure  event  using  Fussell’s  methodology  will  result  in 
identical  fault  trees  [Ref.  3:p  432].  This  indicates  a  level  of  reliability  in  Fussell’s 
methodology,  and  suggests  the  possibility  that  part  or  all  of  the  fault  tree  construction 
may  be  automated. 

2.  Software  Fault  Tree  Analysis 

Leveson  and  Harvey  [Ref.  5:p.  570]  describe  an  analysis  technique  that 
makes  use  of  the  basic  principles  of  fault  tree  analysis,  but  applies  them  to  the  analysis 
of  the  software  of  a  system  rather  than  to  a  system’s  hardware  components.  Since  the 
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basic  notion  of  determining  what  sequence  of  events  are  capable  of  producing  the 
undesired  event  is  the  same  for  the  analysis  of  both  hardware  and  software,  a  software 
tree  can  be  linked  together  with  a  hardware  tree  at  the  appropriate  interface.  This 
allows  the  analysis  of  an  undesired  event  to  span  over  the  entire  hardware/software 
system.  This  linkage  ability  strengthens  software  fault  tree  analysis  (SFTA)  by 
allowing  the  effects  of  a  hardware  failure  on  the  software  system  to  be  analyzed. 

The  value  of  being  able  to  link  together  both  the  hardware  and  the  software 
of  a  system  when  conducting  software  fault  tree  analysis  is  illustrated  by  an  example  of 
a  hazard  resulting  from  missile  launch  control  software  being  tested  for  the  F/A-18 
aircraft  [Ref.  6:p.  3].  The  computer  system  was  being  used  to  control  the  launch  of  a 
wing  mounted  missile.  The  computer  system  was  to  fire  the  missile,  open  the  wing 
station  clamp  to  release  the  missile,  and  then  close  the  clamp.  The  hazard  occurred 
because  the  software  closed  the  clamp  before  the  missile  had  built  up  enough  thrust  to 
leave  the  wing.  This  resulted  in  the  aircraft  having  3000  pounds  of  extra  thrust 
attached  to  the  wing  of  the  aircraft.  The  ability  of  SFTA  to  be  linked  in  with  a 
hardware  fault  tree  presents  the  opportunity  to  fully  analysis  these  interrelated  errors. 

There  are  differences  in  the  approach  that  software  fault  tree  analysis  takes 
in  the  analysis  of  a  software  system  that  sets  this  method  apart  from  the  more 
traditional  hardware  fault  tree  analysis  methods.  A  hardware  fault  tree  relies  on  the 
probabilities  of  failure  for  various  hardware  components.  These  failure  probabilities  are 
either  known,  or  can  be  accurately  predicted.  Hardware  fault  tree  analysis  makes  use 
of  these  probabilities  of  failure  to  construct  a  tree  that  will  show  which  components  are 
critical  to  the  system.  This  tree  construction  based  on  failure  probabilities  is  possible 
since  hardware  components  are  assumed  to  fail  independently  at  a  determinable  rate. 
Software  fault  tree  analysis  cannot  proceed  in  the  same  manner  since  no  such 
assumption  about  failure  independence  can  be  made  about  software  component  failures. 
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[Ref.  5:p.  576]  Furthermore,  since  software  faults  are  design  faults,  determination  of  a 
software  failure  rate  is  an  unsolved  problem  [Ref.  7:p.  104], 

The  approach  taken  by  Leveson  and  Harvey’s  software  fault  tree  analysis  is 
to  use  the  fault  tree  to  show  that  the  logic  of  the  software  design  will  not  produce  or 
contribute  to  actions  that  lead  to  system  failures.  This  analysis  can  take  place  at  any 
desired  level  of  abstraction,  including  code  level  analysis.  If  a  failure  is  shown  to  be 
possible,  the  structure  of  the  resultant  tree  determines  any  environmental  conditions  that 
could  lead  to  the  software  causing  a  safety  failure.  [Ref.  5:p.  576]  Software  fault  tree 
analysis  starts  with  the  assumption  that  the  software  system  has  gotten  itself  into  a  state 
in  which  the  undesired  event  has  occurred.  With  this  assumption,  the  fault  tree  is 
developed  backwards  starting  with  the  undesired  event  and  examines  all  the  possible 
paths  that  lead  to  the  undesired  event.  Typical  usage  starts  with  the  program 
statements  as  written  in  the  implementation  language.  Each  statement  is  assumed  to 
have  executed  in  a  manner  such  that  the  undesired  event  occurs.  The  development 
proceeds  by  looking  at  each  statement  and  determining  how  the  assumed  statement 
execution  was  allowed  to  occur. 

a.  Statement  Templates 

Cha,  Leveson  and  Shimeall  [Ref.  8:pp.  380-383]  present  statement 
templates  (hence  forth  referred  to  as  "Cha’s  Templates"  for  convenience)  that  are  used 
to  analyze  each  of  the  possible  Ada  statements.  The  template  for  the  decision 
statement  shows  all  the  pathways  that  the  software  can  take  when  a  decision  statement 
is  executed.  The  template  for  non-decision  statements  can  be  used  to  analyze  the 
various  possible  results  from  each  statement,  and  can  show  whether  the  execution  of 
the  assignment  statement  could  result  in  another  link  in  the  chain  leading  back  to  the 
undesired  event.  Figure  4  is  an  example  of  a  template  developed  for  an  Ada 
assignment  statement  [Ref.  8:p.  380]. 
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Figure  4.  Ada  Assignment  Statement  Template 

Cha’s  templates  were  designed  using  statement  semantics  from  the  Ada 
language,  and  by  analyzing  the  causes  of  frequently  made  programming  errors.  The 
templates  suggest  possible  branches  to  analyze  specific  statements.  This  aids  the 
analyst  in  the  consideration  of  all  the  possible  results  of  a  statement.  The  authors 
contend  that  templates  could  be  constructed  to  analyze  program  statements  written  in 
any  language,  and  allude  that  the  templates  might  be  tailor  made  to  try  to  uncover 
specific  errors.  This  tailoring  might  make  the  search  for  critical,  system  specific  events 
more  effective. 

b.  Contradiction  Within  Fault  Trees 

With  or  without  the  guidance  of  statement  templates,  every  single 
safety-critical  path  that  the  software  may  take  during  the  course  of  execution  must  be 
analyzed  via  a  branch  in  the  fault  tree.  Ideally,  as  paths  are  analyzed,  contradictions 
will  occur.  A  contradiction  with  regard  to  software  fault  tree  analysis  is  when  an  event 
that  could  cause  the  undesired  event  is  prevented  by  the  software.  Since  the 
contradicted  event  cannot  occur,  that  particular  analysis  branch  need  no  longer  be 
pursued. 
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A  path  that  terminates  without  a  contradiction  is  a  path  via  which  the 
undesired  event  can  occur,  and  actually  proves  that  the  undesired  event  could  possibly 
be  generated  by  the  system  software.  Since  the  exact  path  that  allows  the  undesired 
event  is  now  known,  it  is  a  simple  matter  to  place  run-time  checks  in  the  code  to  halt 
the  pathway  to  the  undesired  event. 

Even  with  the  ability  to  halt  tree  development  after  a  contradiction,  any 
given  fault  tree  may  still  be  lengthy  if  carried  out  to  full  term.  Leveson  and  Harvey 
[Ref.  4:p.  576]  point  out  that  it  is  not  necessary  to  expand  the  entire  tree  down  until 
every  path  terminates  in  either  a  contradiction  or  the  system  environment.  At  any  level 
of  abstraction,  the  analysis  may  be  halted  and  run-time  checks  inserted  into  the  code  to 
trap  a  developing  unsafe  state. 

B.  SAFETY  CRITICAL  CONSIDERATIONS 

The  prospect  of  testing  a  system  using  fault  tree  analysis  may  seem  tempting 
since  this  analysis  method  effectively  proves  whether  or  not  a  system  will  allow  a 
specific  event  to  occur.  However,  testing  deals  primarily  with  determining  whether  or 
not  a  system  will  function  as  it  was  designed  to.  The  purpose  of  testing  a  system  is  to 
attempt  to  show  that  the  system  does  not  meet  its  specification  (Ref.  9:p.  3]. 

Leveson  and  Harvey  [Ref.  5:p.  571]  point  out  that  software  fault  tree  analysis  is 
focused  on  proving  that  the  system  is  incapable  of  producing  a  specific  event  from  a 
software  standpoint.  This  is  much  different  from  testing  to  see  if  a  system  will  provide 
correct  output  for  all  of  a  potentially  infinite  set  of  states  that  the  system  could  be  in 
during  the  course  of  execution.  Focusing  on  proving  that  the  system  cannot  produce  a 
specific  undesired  event  allows  the  analysis  to  take  advantage  of  path  termination  when 
a  contradiction  occurs,  which  makes  for  shallower  trees.  Still,  the  set  of  what  a 
software  system  is  not  supposed  to  do  is  the  complement  of  what  the  system  is 
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supposed  to  do,  with  the  size  of  both  sets  potentially  being  very  large.  To  attempt  to 
use  software  fault  tree  analysis  on  the  set  of  events  that  the  system  is  not  supposed  to 
do  would  require  an  impossibly  large  number  of  fault  trees  to  be  developed.  Since  the 
development  of  a  fault  tree  is  generally  not  a  trivial  undertaking,  the  set  of  events  to  be 
analyzed  must  be  reduced.  The  reduction  of  this  set  is  where  safety  criticality  comes 
in. 

The  inclusion  of  safety  criticality  as  a  means  of  reducing  the  set  of  undesired 
events  with  which  the  software  fault  tree  analysis  must  contend  primarily  relies  on  two 
underlying  concepts.  As  Cha  [Ref.  8:p.  377]  points  out,  the  first  concept  is  that  not  all 
failures  are  of  equal  consequence,  and  the  second  concept  is  that  the  number  of 
potentially  serious  failures  is  relatively  small  as  compared  to  the  overall  set  of 
undesired  events.  Reducing  the  set  of  undesired  events  by  determining  which  events 
are  critical  to  the  safe  operation  of  the  software  system  allows  SFTA  to  be  focused  on 
the  smaller  set  of  potentially  high-cost  or  otherwise  unacceptable  errors. 

C.  PROBLEM  STATEMENT 

The  templates  presented  by  Cha  are  useful  in  guiding  the  statement  by  statement 
decomposition  of  software  fault  trees.  However,  these  templates  are  limited  in 
application  to  line  by  line  code  analysis,  and  do  not  deal  with  undesired  events  not 
linked  to  single  linear  sequences  of  statements.  With  current  software  fault  tree 
analysis  techniques,  no  formal  method  exists  for  decomposing  a  system-level  hazard  to 
the  point  at  which  the  Cha  statement  templates  can  be  applied.  System-level  hazards 
are  currently  decomposed  manually  in  what  proves  to  be  a  largely  human  intensive 
manner.  Decomposition  of  system-level  hazards  in  this  manner  relies  heavily  on 
human  insight  and  knowledge  of  the  software  system,  and  introduces  human  error  in 
the  form  of  oversight. 
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This  thesis  approaches  the  decomposition  of  a  system-level  hazard  from  a 
formalized  standpoint  The  decomposition  of  the  system-level  hazard  primarily 
proceeds  along  two  distinct  but  interdependent  dimensions,  specificity  of  event  and 
subsystem  size.  The  hazard  starts  as  a  more  general  event  that  is  assumed  to  occur 
somewhere  within  a  large  system  or  subsystem.  The  process  of  decomposition  involves 
breaking  the  hazard  into  more  specific  events,  or  itemizing  subsystems  within  which 
the  hazard  may  be  a  consequence.  Decomposing  a  hazard  in  one  dimension  often 
results  in  opening  up  further  possibilities  for  decomposition  along  the  other  dimension. 

The  Specificity-of-Event  decomposition  dimension  deals  with  how  specific  the 
events  and  conditions  associated  with  the  hazard  are.  The  goal  of  this  decomposition 
dimension  is  to  identify  the  particular  events  that  are  to  be  analyzed  within  the 
subsystems  that  comprise  the  system  being  examined.  This  decomposition  works  by 
itemizing  each  event  that  could  cause  the  hazard  in  the  current  subsystem.  For  this 
itemization  to  be  effective,  the  scope  of  the  decomposition  must  constitute  a  complete 
enumeration  of  the  ways  in  which  the  hazard  could  occur  within  the  current  subsystem. 
Although  some  of  these  itemized  events  will  not  be  considered  further,  due  to  the 
contradictions  that  the  events  represent,  all  possible  occurrences  of  the  hazard  are 
itemized  for  completeness.  The  sum  of  these  itemized  events  represents  in  total  the 
ways  in  which  the  hazard  can  occur  within  the  scope  of  the  current  subsystem. 

The  Subsystem-Size  decomposition  dimension  deals  with  how  large  of  a 
subsystem  is  being  considered  when  determining  how  the  hazard  being  analyzed  can 
occur.  This  decomposition  dimension  moves  the  scope  of  the  hazard  from  a  more 
general  system  wide  event,  to  an  event  that  is  more  specific  in  terms  of  the  scope  of 
the  subsystem  that  the  event  effects.  This  increase  in  the  specificity  of  the  event 
effectively  works  to  identify  the  specific  system  events  that  must  be  targeted  for 
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analysis  by  the  statement  templates.  Decomposing  the  hazard  into  various  subsystems 
focuses  the  tree  towards  subsystems  that  play  a  role  in  the  hazard  being  analyzed. 

D.  STRUCTURE  OF  THESIS 

Chapter  II  develops  the  design  of  templates  that  provide  a  framework  for 
decomposing  a  system-level  hazard  to  the  point  at  which  line  by  line  code  analysis  can 
be  conducted  with  existing  statement  templates.  These  templates  serve  as  guides  for 
conducting  the  decomposition,  and  ensure  that  as  many  as  possible  of  all  the  applicable 
decomposition  aspects  are  evaluated. 

Chapter  III  demonstrates  the  use  of  the  decomposition  templates  through  an 
example.  The  fault  tree  is  developed  starting  with  the  decomposition  of  an  undesired 
system-level  event.  Events  are  further  decomposed  using  the  templates  developed  in 
Chapter  II  indicating  specific  modules  of  the  software  system  along  with  associated 
specific  events  and  conditions.  This  decomposition  process  is  continued  until  the  point 
at  which  Cha’s  statement  templates  can  be  implemented. 

Chapter  IV  summarizes  the  work  accomplished  through  the  use  of  the 
decomposition  templates,  and  the  conclusions  that  were  drawn  through  the  development 
of  this  thesis.  Areas  of  future  work  in  the  area  of  software  event  decomposition 
templates  are  indicated  in  this  chapter. 
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n.  DECOMPOSITION  TEMPLATES 


A.  DECOMPOSITION  OF  A  HAZARD 

The  hazard  at  the  root  of  the  software  fault  tree  is  decomposed  in  a  manner  such 
that  statement  templates  may  be  used  to  analyze  the  hazard  at  the  statement  level  of 
each  applicable  subsystem.  The  hazard  is  decomposed  in  two  different  abstract 
dimensions.  As  depicted  by  Figure  5,  these  decomposition  dimensions  are  the 
specificity  of  the  event  being  considered,  and  the  size  of  the  subsystem  being 
considered. 


Specific 
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Figure  5.  Decomposition  Dimensions 


Figure  5  shows  the  hazard  starting  as  a  more  general  event  that  occurs 
somewhere  in  a  large  system  or  subsystem.  The  process  of  decomposition  involves 
breaking  the  hazard  into  more  specific  events,  or  itemizing  subsystems  within  which 
the  hazard  may  be  a  consequence,  or  both.  In  both  dimensions  of  the  graph  in  Figure 
5,  the  path  that  the  decomposition  process  takes  is  non-decreasing  in  nature.  For 
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example,  the  Specificity-of-Event  dimension  may  be  held  constant  so  as  to  allow  the 
other  dimension,  Subsystem-Size,  to  move  more  to  the  right  as  it  is  decomposed. 
However,  the  Specificity-of-Event  dimension  does  not  move  towards  a  more  general 
event  to  allow  the  Subsystem-Size  dimension  to  move  from  a  larger  to  a  smaller 
subsystem  size.  A  move  such  as  this  results  in  backtracking  within  the  analysis  tree. 
Although  a  backtracking  move  would  be  required  when  the  analyst  determines  that  a 
previous  move  was  incorrect,  backtracking  effectively  accomplishes  nothing  more  than 
returning  to  a  previous  state  so  that  the  analysis  can  take  an  alternate  avenue. 


B.  SOFTWARE  SYSTEM  REQUIREMENTS 

In  order  to  illustrate  each  decomposition  template  as  it  is  presented,  a  simple 

software  program  is  used.  The  following  requirements  for  an  imaginary  traffic  light 

control  program  for  an  automobile  intersection  was  used  by  Cha,  Leveson  and  Shimeall 

in  demonstrating  the  use  of  software  statement  templates,  and  is  repeated  here  : 

"A  traffic  light  control  system  at  an  intersection  consists  of  four  (identical) 
sensors  and  a  central  controller.  The  sensors  in  each  direction  detect  cars 
approaching  the  intersection.  If  the  traffic  light  currently  is  not  green,  the  sensor 
notifies  the  controller  so  that  the  light  will  be  changed.  A  car  is  expected  to  stop 
and  wait  for  a  green  light.  If  the  light  is  green  already,  the  car  may  pass  the 
intersection  without  stopping.  The  controller  accepts  change  requests  from  the 
four  sensors  and  arbitrates  the  traffic  light  changes.  Once  the  controller  changes 
the  light  in  one  direction  (east-west  or  south-north)  to  green,  it  maintains  the 
green  signal  for  five  seconds  so  that  other  cars  in  the  same  direction  may  pass  in 
the  same  direction  without  stopping.  Before  the  green  light  in  any  direction 
becomes  red,  it  should  remain  in  yellow  for  one  second  so  that  any  car  present  in 
the  intersection  may  clear.  The  light  then  turns  to  red  while  the  light  in  the 
opposite  direction  turns  to  green."  [Ref.  8:p.  382] 

With  the  above  requirements,  the  hazard  analyzed  to  illustrate  the  decomposition 

templates  is  "Two  Cars  Simultaneously  in  Intersection  Traveling  in  Perpendicular 

Directions",  or  "Perpendicular  Cars"  for  short.  As  noted  by  Cha,  the  above 

requirements  were  designed  to  contain  several  failure  modes.  Finding  failure  modes 

other  than  the  one  illustrated  by  Cha  have  no  relevance  to  the  importance  of  Cha’s 
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work.  Hazard  decomposition  as  presented  herein  is  intended  to  precede  and 
complement  Cha’s  work  on  statement  templates.  The  application  of  statement  templates 
completes  the  hazard  decomposition  presented  in  this  thesis. 

C.  SPECIFICITY-OF-EVENT  DECOMPOSITION  DIMENSION 

The  Specificity-of-Event  decomposition  deals  with  how  specific  the  events  and 
conditions  associated  with  the  hazard  are.  The  goal  of  decomposing  the  hazard  with 
regard  to  specificity  is  to  identify  the  particular  events  that  are  to  be  analyzed  within 
the  subsystems  that  comprise  the  system  being  examined.  This  decomposition  works 
by  itemizing  each  event  that  could  cause  the  hazard  in  the  current  subsystem.  For  this 
itemization  to  be  effective,  the  scope  of  the  decomposition  must  constitute  a  complete 
enumeration  of  the  ways  in  which  the  hazard  could  occur  within  the  current  subsystem. 
Although  some  of  these  itemized  events  will  not  be  considered  further  due  to  the 
contradictions  that  the  events  represent,  all  possible  occurrences  of  the  hazard  are 
itemized  for  completeness.  The  sum  of  these  itemized  events  represents  in  total  the 
ways  in  which  the  hazard  can  occur  within  the  scope  of  the  current  subsystem. 

D.  SPECIFICITY-OF-EVENT  DECOMPOSITION  TEMPLATES 

Three  basic  logic  relations,  OR  NOT  and  AND,  are  used  to  determine  the 
relationship  of  the  events  itemized  by  the  decomposition  process.  The  following 
templates  show  the  logical  relationship  that  the  decomposed  event(s)  and  condition(s) 
have  to  the  hazard. 

1.  OR  Template 

The  OR  Template  (Figure  6)  is  used  to  decompose  a  hazard  that  occurs 
because  either  one  of  two  events  (Event  1  or  Event  2)  occur.  Both  Event  1  and  Event 
2  are  capable  of  singularly  causing  the  hazard  to  occur.  Since  either  Event  1  or  Event 
2  could  cause  the  hazard,  each  event  is  given  its  own  branch  within  the  OR  gate.  The 
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Figure  6.  OR  Template 

center  branch  within  the  OR  gate  is  reserved  for  the  instance  in  which  both  Event  1 
and  Event  2  occur  simultaneously.  Further  decomposition  on  this  center  branch 
generally  is  halted  immediately  because  in  order  for  this  branch  to  be  taken  during 
analysis,  both  events  must  occur.  If  both  events  occur,  then  the  hazard  will  occur  the 
same  as  if  only  one  of  the  events  had  occurred.  The  analysis  of  the  center  branch  may 
be  a  direct  duplication  of  the  analysis  of  the  two  separate  events,  and  in  that  case  it  is 
not  further  pursued.  Only  if  the  center  event  suggests  important  and  non-duplicative 
analysis  directions  is  it  explored.  For  example,  if  the  two  events  leading  to  a  hazard 
are  not  independent,  the  center  branch  could  be  used  to  explore  their  interdependency 
as  a  source  of  the  undesired  event.  If  the  center  branch  is  irrelevant,  it  is  omitted  from 
the  analysis. 

An  example  of  the  decomposition  of  the  hazard  using  a  OR  Template 
(Figure  7)  in  the  traffic  light  control  system  is  found  in  the  requirements.  The 
requirements  state  that  before  the  green  light  in  any  direction  becomes  red,  it  should 
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Figure  7.  Example  OR  Template  Use 

remain  in  yellow  for  one  second  so  that  any  car  presently  in  the  intersection  may  clear. 
If  the  software  fails  to  make  each  light  pause  in  yellow  for  one  second  during  the 
transition  from  green  to  red,  a  car  could  get  caught  in  the  intersection  when  the 
opposing  traffic  light  turns  green.  One  branch  of  the  OR  Template  for  the 
decomposition  of  Perpendicular  Cars  is  the  event  "No  Pause  in  Yellow  When  Light 
Commanded  From  Green  to  Red".  Another  branch  considered  here  is  the  software 
system’s  command  of  the  lights.  If  the  software  were  to  command  perpendicular  lights 
to  be  green  at  the  same  time,  the  Perpendicular  Cars  hazard  could  occur.  This 
decomposition  represents  the  second  branch  as  "Software  Commands  Perpendicular 
Lights  Green". 

2.  NOT  Template 

The  NOT  Template  (Figure  8)  is  used  to  decompose  a  hazard  that  occurs 
because  an  event  or  action  fails  to  occur.  The  logical  NOT  decomposes  the  hazard 
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such  that  it  is  not  the  case  that  the  event  does  occur.  This  frees  the  analyst  to  consider 
the  case  in  which  the  event  does  occur.  As  with  a  mathematical  proof  by 
contradiction,  it  may  be  more  straightforward  to  show  that  there  is  a  contradiction  with 
assuming  that  an  event  does  occur  than  it  is  to  show  that,  for  all  cases,  it  is  impossible 
for  the  event  to  occur  within  the  system.  An  example  of  the  use  of  a  NOT  Template 
(Figure  9)  is  the  "No  Pause  in  Yellow  When  Light  Commanded  From  Green  to  Red" 
Branch  of  the  example  OR  Template  hazard  decomposition  appearing  in  Figure  7.  By 


Figure  8.  NOT  Template  Figure  9.  Example  NOT  Template 

applying  the  NOT  Template,  the  event  "Light  Pauses  in  Yellow  When  Light  Goes 
From  Green  to  Red"  could  instead  be  analyzed  if  this  event  is  deemed  more 
straightforward  to  evaluate. 

3.  AND  Templates 

A  logical  AND  is  represented  with  two  different  AND  decomposition 
templates.  The  first  AND  Template  (Figure  10)  is  used  to  decompose  a  hazard  that 
occurs  because  both  of  two  separate  events  (Event  1  and  Event  2)  occur.  This 
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Figure  10.  AND  Template 

decomposition  template  breaks  the  hazard  into  two  events,  each  of  which  is  analyzed 
individually.  If  either  of  the  events  can  be  shown  to  be  incapable  of  occurring,  the 
analysis  of  both  of  the  AND  branches  is  stopped. 

An  example  of  the  use  of  the  AND  Template  (Figure  11)  is  to  further 
decompose  the  "Software  Commands  Perpendicular  Lights  Green"  branch  of  the  OR 
Template.  To  decompose  this  branch  further,  consideration  must  be  given  as  to  how 
the  software  could  end  up  in  a  state  in  which  perpendicular  lights  have  been 
commanded  green.  One  way  for  this  event  to  occur  is  if  the  software  properly 
commands  a  light  green,  while  at  the  same  time  the  perpendicular  light  is  stuck  in  a 
green  state. 

The  second  AND  (WHILE/WHEN)  Template  (Figure  12)  is  used  to 
decompose  a  hazard  that  occurs  because  an  event  occurs  while  a  specific  condition  is 
true.  If  the  condition  does  not  hold  while  the  event  occurs,  then  the  hazard  does  not 
occur.  Thus,  the  event  is  dependant  upon  the  condition  associated  to  it  by  the  AND 
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Figure  11.  Example  AND  Template  Use 


gate.  All  subsequent  decompositions  resulting  from  the  event  side  of  the  AND  gate 
carry  with  them  the  scope  of  the  condition  side. 


Hazara  Occurs  Because  Eveni  Occurs 
While  or  When  Condition  is  True 


0 


Eveni  Occurs 


^Conaaion^ 


Figure  12.  AND  (WHILE/WHEN)  Template 
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An  example  of  the  use  of  the  AND  (WHELE/WHEN)  Template  (Figure  13) 
is  to  further  decompose  the  "No  Pause  in  Yellow  When  Light  Commanded  From  Green 


Figure  13.  Example  AND  (WHILE/WHEN)  Template  Use 


to  Red"  branch  of  the  example  OR  Template  hazard  decomposition  in  Figure  7.  This 
event  is  broken  down  into  an  event  and  a  condition  that  must  be  true  in  order  for  the 
associated  event  to  result  in  the  occurrence  of  the  hazard.  The  event  is  decomposed 
using  an  AND  (WHILE/WHEN)  Template  into  the  event  "Light  Does  Not  Pause  in 
Yellow"  and  the  condition  "Light  Commanded  From  Green  to  Red". 

E.  HIGH-LEVEL  TRAFFIC-LIGHT  DESIGN 

For  the  purposes  of  demonstrating  the  subsystem  decomposition  templates,  a 
simple  high  level  design  loosely  fulfilling  the  requirements  for  Cha’s  stoplight  system  is 
represented  in  the  High-Level  Traffic-Light  Design  (Figure  14).  This  high-level  design 
has  a  "controller"  process  which  determines  how  the  four  lights  should  be  set,  and 
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sends  commands  for  changing  the  lights  to  four  identical  "Set  Signal"  processes.  The 
four  "Set  Signal"  processes  in  turn  control  the  four  traffic  light  devices. 


Figure  14.  High-Level  Traffic-Light  Design 


When  the  "Controller"  process  determines  a  light  should  be  changed  from  green 
to  red,  the  "Controller"  process  is  responsible  for  ensuring  that  the  light  pauses  in 
yellow  during  the  transition.  Each  "Set  Signal"  process  controls  one  of  the  four 
physical  traffic  signals  in  the  intersection,  and  sends  green,  yellow,  and  red  indications 
to  the  traffic  light  as  directed  by  the  "Controller"  process.  The  "Controller"  process 
determines  how  the  four  lights  should  be  set  by  accepting  input  both  from  a  clock  and 
from  the  four  identical  "Read  Car  Sensor"  processes.  Each  "Read  Car  Sensor"  process 
reads  sensor  hardware  that  indicates  when  a  car  has  approached  the  intersection.  The 
"Controller"  process  uses  input  from  the  clock  device  to  ensure  that  the  light  has 
remained  green  in  one  direction  long  enough  to  allow  a  predetermined  minimum 
number  of  cars  through  the  intersection.  This  high-level  design  is  by  no  means 
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complete,  and  is  intended  to  be  a  tool  for  demonstration  of  the  use  of  subsystem 
decomposition  templates. 

F.  SUBS Y STEM-SIZE  DECOMPOSITION  DIMENSION 

The  Subsystem-Size  decomposition  dimension  deals  with  how  large  a  subsystem 
is  being  considered  when  determining  how  the  hazard  being  analyzed  can  occur.  The 
size  of  the  subsystem  may  start  out  comprising  the  entire  software  and  hardware  system 
in  the  beginning  of  the  decomposition.  This  decomposition  moves  from  a  more  general 
system  wide  event,  to  an  event  that  is  more  specific  in  terms  of  the  scope  of  the 
subsystem  that  the  event  effects.  This  increase  in  the  specificity  of  the  event 
effectively  works  to  identify  the  specific  system  events  that  must  be  targeted  for 
analysis  by  the  statement  templates.  Decomposing  the  hazard  into  various  subsystems 
focuses  the  tree  towards  subsystems  that  play  a  role  in  the  hazard  being  analyzed. 

Along  with  indicating  which  subsystems  should  be  investigated,  the  software  fault 
tree  must  indicate  any  conditions  or  events  that  must  be  considered  when  analyzing  the 
subsystem  on  a  statement  by  statement  basis.  These  conditions  and  events  are 
indicated  through  the  previously  described  AND  (WHILE/WHEN)  template  (Figure  12). 
The  focus  of  the  templates  presented  below  is  to  decompose  the  overall  software 
system  with  the  intent  of  identifying  the  subsystems  that  can  contribute  to  the 
occurrence  of  the  hazard.The  decomposition  of  a  system  into  its  various  subsystems 
relies  on  the  communication  links  and  interfaces  with  which  the  system  will  function. 
In  order  to  demonstrate  the  use  of  subsystem  decomposition  templates,  the  high-level 
design  for  the  traffic  light  system  previously  described  is  used  to  represent  the 
communication  between  the  processes  of  the  subsystem. 
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G.  SUBSYSTEM-SIZE  DECOMPOSITION  TEMPLATES 


1.  Subsystem  Template 

Subsystem  decomposition  templates  are  used  to  break  out  from  the  overall 
system  the  various  systems  and  subsystems  that  must  be  considered  in  regard  to  the 
hazard.  Three  templates  are  used  for  the  decomposition  of  subsystems,  and  are  related 
via  an  OR  gate  as  shown  in  the  Subsystem  Template  (Figure  15). 

At  the  root  of  the  Subsystem  Template  is  the  subsystem  that  is  indicated  by 
the  hazard  or  event  The  Process  Template  branch  decomposes  the  subsystem  based 


t 


Figure  15. 


C  'A/lAA  >  \  J-  tA/ffrV, 

1  C  '/  i  ( 

Subsystem  Template 


upon  the  input-process-output  of  a  subsystem.  The  Communication  Template  branch 
decomposes  the  subsystem  based  upon  the  communication  between  various  processes 
within  a  subsystem.  The  Access  Template  branch  decomposes  the  subsystem  based 
upon  the  access  that  a  subsystem  may  have  to  a  device  or  database. 
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An  example  of  the  use  of  the  Subsystem  Template  (Figure  16)  is  to 
decompose  the  event  "No  Pause  in  Yellow  When  Light  Commanded  From  Green  to 
Red"  from  the  left  branch  of  the  example  OR  Template  (Figure  7).  At  this  point,  the 
entire  system  is  considered  when  determining  which  subsystems  to  decompose  based 
upon  this  event  Subsequent  decompositions  using  the  Subsystem  Template  would  use 
the  scope  of  the  subsystem  that  is  currently  being  evaluated  as  the  root  subsystem  of 
the  template. 


Figure  16.  Example  Subsystem  Template  Use 


To  evaluate  the  event  "No  Pause  in  Yellow  When  Light  Commanded  From 
Green  to  Red"  for  subsystem  decomposition,  the  analyst  must  determine  from  the 
system  design  the  processes  that  control  the  traffic  light,  the  subsystem(s)  that 
communicate  with  these  controlling  processes,  and  the  processes  that  actually  have 
access  to  the  traffic  light.  The  processes  that  can  be  decomposed  from  the  system  are 
determined  by  evaluating  the  High-Level  Traffic-Light  Design  (Figure  14). 
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As  shown  in  Figure  16,  the  "Controller"  process  is  indicated  in  the  left 
branch  of  the  template  because  it  is  the  process  within  the  system  that  controls  the 
traffic  light  by  sending  commands  to  set  the  traffic  signal  to  the  "Set  Signal"  process. 
The  middle  branch  of  Figure  16  indicates  that  all  the  processes  that  communicate  with 
the  "Controller"  process  must  be  considered  by  the  decomposition.  The  right  branch  of 
Figure  16  indicates  that  all  processes  that  actually  have  access  to  the  traffic  light  should 
also  be  considered  in  this  decomposition  step. 

2.  Process  Template 

The  Process  Template  (Figure  17)  is  used  to  decompose  the  subsystem  by 
evaluating  the  three  basic  areas  of  the  subsystem.  These  three  areas  are  distinguishable 
by  their  relation  to  the  overall  process  contained  within  the  subsystem. 


Figure  17.  Process  Template 
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The  first  branch  of  the  Process  Template  (Figure  17),  Input  To  Process, 
decomposes  the  subsystem  by  considering  the  input  to  the  subsystem  from  either  a 
larger  subsystem  within  which  the  current  subsystem  is  contained,  or  input  from  the 
environment  within  which  the  subsystem  operates.  The  input  to  the  process  within  the 
subsystem  is  decomposed  to  evaluate  whether  or  not  input  to  the  process  can  cause  the 
hazard  to  occur. 

The  second  branch  of  the  Process  Template  (Figure  17),  Internal  Process, 
deals  with  the  overall  process  that  the  current  subsystem  performs.  As  shown  by  the 
Process  Template,  the  overall  process  itself  can  be  decomposed  into  subprocesses  1-N. 
The  total  number  of  subprocesses  (N)  is  limited  because  of  the  safety  critical  nature  of 
the  system  being  analyzed.  If  N  is  excessively  large,  then  the  system  is  inherently 
unsafe  because  the  safety  critical  processes  cannot  reliably  be  isolated.  The  Process 
Template  is  designed  for  use  on  systems  with  a  relatively  small  number  of  safety 
critical  subprocesses.  These  N  subprocesses  are  considered  in  two  ways,  individually 
and  in  combination. 

Under  the  Individual  Subprocess  branch  of  the  Process  Template  (Figure 
17),  each  subprocess  is  considered  individually  to  determine  if  any  one  of  the  N 
subprocesses  can  by  itself  result  in  the  occurrence  of  the  hazard.  Each  subprocess  is 
strictly  evaluated  in  isolation,  with  no  interaction  allowed  from  any  other  subprocess. 
If  a  subprocess  always  requires  interaction  with  other  subprocesses,  then  the  individual 
subprocess  decomposition  is  stopped.  A  subprocess  requiring  interaction  is  evaluated 
under  the  Subprocess  Interaction  branch  of  the  Process  Template. 

The  second  way  in  which  the  Process  Template  (Figure  17)  considers  the  N 
subprocesses  that  are  decomposed  via  the  Internal  Process  branch  is  through  the 
evaluation  of  the  interaction  of  one  of  the  N  subprocesses  with  another  of  the  N 
subprocesses.  The  decomposition  of  the  process  of  a  subsystem  that  takes  advantage  of 
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parallel  processing  must  consider  the  different  combinations  of  subsystems  that  are 
capable  of  processing  in  parallel.  From  this  set  of  combinations,  the  software  fault  tree 
must  consider  whether  any  of  the  combinations  are  capable  of  interacting  in  a  manner 
that  would  result  in  the  occurrence  of  the  hazard. 

The  third  branch  of  the  Process  Template  (Figure  17),  Output  of  Process, 
decomposes  the  subsystem  by  considering  the  output  that  is  produced  by  the  overall 
process  that  the  current  subsystem  performs.  The  output  from  the  process  is  evaluated 
to  consider  whether  the  output  can  cause  the  hazard  to  occur. 

An  example  of  the  use  of  the  Process  Template  (Figure  18)  is  to  decompose 
the  "Controller"  process  of  the  high-level  traffic  light  design.  The  decomposition  starts 
with  the  analyst  pursuing  the  "No  Pause  in  Yellow  When  Light  Commanded  From 
Green  to  Red"  event  branch  of  the  example  OR  Template  (Figure  7).  The  analyst 
determines  that  the  "Controller"  process  is  a  process  that  could  be  indicated  by  the 
occurrence  of  this  event. 


Figure  18.  Example  Process  Template  Use 
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The  "Controller"  process  is  decomposed  into  three  areas  as  shown  in  Figure 
18.  The  first  branch  of  the  Process  Template  indicates  that  the  internal  processes 
within  the  "Controller"  process  should  be  analyzed.  The  second  branch  "Input  to 
Process"  indicates  that  the  four  "Read  Car  Sensor"  processes  and  the  "Clock"  process 
should  be  analyzed  since  these  processes  provide  input  to  the  "Controller"  process. 
The  third  branch  indicates  that  the  output  from  the  "Controller"  process  to  the  four  "Set 
Signal"  processes  should  be  analyzed  to  determine  if  the  event  in  question  could  be  a 
result  of  what  is  output  by  the  "Controller"  process. 

3.  Communication  Template 

The  Communication  Template  (Figure  19)  is  used  to  decompose  a  subsystem 
based  upon  the  communication  between  the  processes  that  make  up  the  subsystem. 
Processes  can  communicate  via  a  rendezvous  (as  in  Ada),  through  shared  memory,  or 
through  the  exchange  of  data. 


Figure  19.  Communication  Template 
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The  communication  that  can  occur  through  a  Ada  rendezvous  is  checked 
using  the  Rendezvous  branch  of  the  Communication  Template  to  determine  if  the 
hazard  can  occur  here.  Processes  that  communicate  through  rendezvous  are  analyzed  in 
a  manner  similar  to  the  way  in  which  processes  communicating  through  the  exchange 
of  data  are  analyzed.  The  two  processes  that  rendezvous  in  effect  join  to  form  one 
overall  process.  This  combined  overall  process  is  then  analyzed  using  the  Process 
Template. 

For  processes  that  communicate  through  shared  memory,  each  process  is 
analyzed  under  the  Shared  Memory  Branch  of  the  Communication  Template  with 
consideration  given  to  changes  to  the  shared  memory  that  the  first  process  can  make. 
These  changes  may  cause  the  second  process  to  function  in  a  manner  such  that  the 
hazard  occurs.  As  with  the  Process  Template,  the  number  of  safety  critical  processes 
that  communicate  through  shared  memory  must  be  small.  If  the  number  of  safety 
critical  processes  communicating  through  shared  memory  is  excessively  large,  then  the 
system  is  inherently  unsafe  because  the  safety  critical  processes  cannot  reliably  be 
isolated. 

Whether  or  not  the  hazard  can  occur  by  way  of  the  exchange  of  data 
through  output  from  one  process  and  input  to  another  process  is  considered  through  the 
use  of  Process  Templates.  In  the  Exchange  of  Data  branch  of  the  Communication 
Template  (Figure  19),  the  two  processes  exchanging  data  are  considered  joined  together 
to  form  a  single  combined  process.  This  combination  process  is  then  evaluated  under 
the  Process  Template.  The  data  that  is  output  from  the  first  process  is  analyzed  using 
the  Output  of  Process  branch,  while  the  data  that  is  exchanged  as  input  is  evaluated 
using  the  Input  to  Process  branch. 

An  example  of  the  Communication  Template  (Figure  20)  is  limited  by  the 
simplicity  of  the  example  high-level  traffic-light  design.  At  this  level,  neither  the 
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Figure  20.  Example  Communication  Template  Use 


processes  that  communicate  through  rendezvous  type  operations,  nor  the  processes  that 
communicate  through  shared  memory  are  known.  The  first  and  second  branches  of  the 
Communication  Template  are  therefore  not  pursued  in  the  example. 

The  third  branch  of  the  Communication  Template  is  used  to  ensure  that  all 
the  processes  that  communicate  with  the  "Controller"  process  are  considered  when 
analyzing  the  "Controller"  process  with  regard  to  the  hazard.  As  indicated  by  Figure 
20,  there  are  three  distinct  sets  of  processes  that  communicate  with  the  "Controller" 
process  through  the  exchange  of  data.  These  sets  of  processes  are  the  four  "Read  Car 
Sensor"  processes,  the  "Clock"  process,  and  the  four  "Set  Signal"  processes.  As  shown 
by  Figure  20,  each  of  these  distinct  sets  of  processes  must  be  analyzed  for  any  role 
they  might  play  in  the  "Controller"  process  causing  the  event,  "No  Pause  in  Yellow 
When  Light  Commanded  From  Green  to  Red". 
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4.  Access  Template 

The  Access  Template  (Figure  21)  is  used  to  decompose  the  subsystem  by 
evaluating  the  access  that  the  subsystem  has  to  the  control  of  a  device  or  the 
maintenance  of  a  database. 


Figure  21.  Access  Template 

Using  the  Access  to  Device  branch  of  the  Access  Template,  a  subsystem 
controlling  a  device  is  evaluated  to  determine  if  the  subsystem  can  control  the  device  in 
a  manner  such  that  the  hazard  can  occur.  As  shown  in  the  Access  To  Device  Template 
(Figure  22),  the  analysis  of  a  subsystem’s  access  to  a  device  consists  of  three  distinct 
evaluation  conditions. 

The  First  evaluation  condition  of  the  Access  to  Device  Template  is  that  the 
subsystem  must  have  access  to  the  device  that  causes  the  hazard.  The  second 
evaluation  condition  is  that  the  subsystem  must  be  capable  of  sending  commands  to  the 
device,  with  the  hazard  occurring  as  a  result  of  the  device  receiving  these  commands. 
The  third  evaluation  condition  is  that  the  subsystem  actually  sends  the  hazard-causing 
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commands  to  the  device.  These  evaluation  conditions  are  AND’d  together  because  in 
order  for  the  subsystem  to  cause  the  hazard  through  its  access  to  the  device,  all  three 
of  these  conditions  must  be  met. 

In  a  similar  manner,  the  Access  to  Database  branch  of  the  Access  Template 
(Figure  23)  is  used  to  determine  if  a  subsystem  maintaining  a  database  can  make 


Figure  22.  Access  To  Device  Template 

entries  or  updates  to  the  database  that  can  result  in  a  process  accessing  the  database 
values  and  utilizing  these  values  in  such  a  manner  that  the  hazard  occurs.  As  shown  in 
the  Access  To  Database  Template,  the  analysis  of  a  subsystem’s  access  to  a  database  is 
evaluated  using  three  distinct  conditions. 

The  first  evaluation  condition  is  that  the  subsystem  must  have  write  access 
to  the  database  from  which  values  that  cause  the  hazard  are  referenced. 

The  second  evaluation  condition  is  that  the  subsystem  must  be  capable  of 
writing  values  to  the  database,  with  the  hazard  occurring  as  a  result  of  a  process 
referencing  these  values.  Here,  the  removal  of  a  value  from  the  database  and  having 
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Figure  23.  Access  To  Database  Template 

the  hazard  occur  as  a  result  of  this  removal  is  considered  as  an  overwrite  of  an  original 
valid  value. 

The  third  evaluation  condition  is  that  the  subsystem  actually  writes  the 
hazard-causing  value  to  the  database.  These  evaluation  conditions  are  AND’d  together 
because  in  order  for  the  subsystem  to  cause  the  hazard  through  its  access  to  the 
database,  all  three  of  these  conditions  must  be  met. 

An  example  of  the  use  of  the  Access  To  Device  branch  of  the  Access 
Template  is  the  decomposition  of  the  Output  of  Process  branch  of  the  Process  Template 
example  (Figure  17).  This  branch  indicates  that  the  "Set  Signal"  processes  need  to  be 
analyzed  to  determine  if  the  "No  Pause  in  Yellow  When  Light  Commanded  From 
Green  to  Red"  event  could  be  caused  within  these  processes.  The  Example  Access  To 
Device  Template  (Figure  24)  shows  how  a  subsystem  causing  the  "No  Pause  in 
Yellow"  hazard  is  considered. 

Each  "Set  Signal"  process  has  access  to  a  traffic  light  since  these  processes 
control  the  changing  of  the  traffic  lights,  so  these  processes  are  indicated  in  the  first 


35 


Figure  24.  Example  Access  To  Device  Template  Use 


branch  of  the  example.  In  the  second  branch  of  the  example,  the  commands  that  these 
processes  give  to  the  traffic  light  must  be  analyzed  to  determine  if  it  is  possible  for 
these  processes  to  send  commands  that  could  cause,  in  this  example,  the  light  to  not 
pause  in  yellow  when  changing  from  green  to  red.  The  third  branch  of  the  example 
indicates  that  the  hazard-causing  commands  indicated  by  the  second  branch  must 
actually  be  sent  to  the  traffic  light  in  order  for  the  hazard  to  occur. 

H.  TIME  RELATIONSHIP  OF  EVENTS 

The  decomposition  of  the  hazard  event  carries  with  it  the  implication  of  going 
back  in  time.  As  an  event  is  decomposed,  all  the  breakdowns  that  are  the  result  of  the 
decomposition  have  the  requirement  of  occurring  simultaneously  with  the  hazard,  or  at 
some  time  prior  to  the  occurrence  of  the  hazard.  SFTA  must  go  backward  in  time 
from  the  occurrence  of  the  hazard  so  that  the  system  can  be  established  in  a  normal 
safe  operational  state.  The  implication  of  the  fault  tree  being  backed  out  all  the  way  to 
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the  initialization  of  the  system  without  ending  in  a  safe  operational  state  is  that  the 
unsafe  event  is  not  prevented  by  the  system. 

The  Time  Template  (Figure  25)  shows  an  event  that  is  decomposed  into  an  event 
that  must  occur  first  in  order  for  the  later  event  to  occur.  This  decomposition  is  based 


Figure  25.  Time  Template 

upon  the  logical  implication,  "if  A  implies  B  and  B  implies  C,  then  A  implies  C",  and 
carries  with  it  the  relationship  of  the  events  with  regard  to  time.  In  Figure  25,  Event  1 
is  the  event  that  the  fault  tree  indicates  would  cause  the  occurrence  of  the  hazard. 
Event  2  is  an  event  that  causes  Event  1  to  occur.  The  link  between  the  two  events  is 
that  Event  2  must  occur  before  Event  1.  Although  Event  2  by  itself  does  not  directly 
cause  the  hazard  to  occur,  Event  2  must  be  considered  due  to  its  relationship  with 
Event  1.  Because  Event  2  causes  Event  1  to  occur,  Event  2  indirectly  causes  the 
occurrence  of  the  hazard. 

An  example  of  the  use  of  the  Time  Template  (Figure  26)  can  be  found  by 
modifying  the  requirements  of  the  traffic  light  control  system.  The  modification  is  that 
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one  of  the  roads  leading  to  the  intersection  has  a  blind  curve  that  must  be  driven 
through  just  prior  to  entering  the  intersection.  On  the  curve  prior  to  the  intersection  is 
a  flashing  yellow  light  that  serves  to  warn  motorists  that  an  intersection  with  a  traffic 
light  lies  ahead. 

Figure  26  shows  how  the  Time  Template  can  be  used  to  decompose  an  event  into 
a  second  event  that  precedes  and  causes  the  first  event  to  occur.  The  event  that  causes 


Figure  26.  Example  Time  Template  Use 


the  "Perpendicular  Cars"  hazard  is  a  car  entering  the  intersection  against  a  traffic  light 
that  is  displaying  a  red  signal.  The  event  of  entering  the  intersection  against  a  red  light 
could  indirectly  be  caused  by  the  flashing  yellow  warning  light  being  inoperative. 
Without  the  warning  to  slow  down  on  the  blind  curve  prior  to  the  intersection,  the 
motorist  does  not  have  enough  room  to  stop  the  vehicle,  given  reaction  time  and 
stopping  distances  for  a  car  traveling  at  normal  speed.  Thus,  the  failure  of  the  flashing 
yellow  warning  light  indirectly  causes  the  "Perpendicular  Cars"  hazard. 
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I.  INTERDEPENDENCE  OF  DECOMPOSITION  DIMENSIONS 


The  two  decomposition  dimensions,  Specificity-of-Event  and  Subsystem-Size,  are 
dependant  on  each  other.  Both  are  goals  of  the  hazard  decomposition.  The  specificity 
of  an  event  can  be  made  more  specific  as  a  means  of  aiding  in  the  decomposition  of  a 
subsystem’s  size.  In  a  similar  manner,  the  decomposition  of  a  subsystem’s  size  serves 
as  a  means  of  making  the  targeted  event  more  specific.  As  the  Decomposition 
Dimensions  in  Figure  5  at  the  beginning  of  the  chapter  shows,  the  decomposition  of  a 
hazard  occurs  along  two  distinct  dimensions,  specificity  of  event  and  subsystem  size. 
As  the  system  is  analyzed,  either  decomposition  dimension  can  be  used  as  a  means  of 
decomposing  the  hazard.  The  templates  presented  in  this  chapter  form  a  framework 
from  which  it  is  possible  to  decompose  the  hazard  along  either  of  the  two  dimensions. 
As  the  hazard  analysis  proceeds,  it  may  be  advantageous  to  decompose  the  hazard  or 
event  with  the  intent  of  making  the  other  decomposition  dimension  more  useful.  In 
other  words,  to  advance  the  Subsystem-Size  decomposition,  the  Specificity-of-Event 
decomposition  dimension  may  be  invoked  specifically  to  help  the  analyst  advance  the 
Subsystem-Size  decomposition.  In  the  following  chapter,  the  framework  of 
decomposition  dimensions  and  decomposition  templates  presented  in  this  chapter  are 
applied  to  a  more  complicated  example. 
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in.  APPLICATION  OF  DECOMPOSITION  TEMPLATES 


A.  ONE-LANE  BRIDGE  REQUIREMENTS  MODEL 

In  this  chapter,  the  decomposition  templates  presented  in  Chapter  II  are  applied  to 
the  requirements  model  of  a  software  system  developed  by  Ripps  [Ref.  10:p.  32]  in  his 
work  on  the  development  of  real  time  requirements.  This  software  system  is  being 
designed  to  control  the  traffic  flow  on  a  one-lane  bridge.  As  depicted  by  Figure  27, 
the  one-lane  bridge  is  shared  by  both  lanes  of  a  dual-lane  road.  The  software  system 
controls  access  to  the  bridge  through  the  use  of  traffic  lights,  and  is  to  keep  traffic 
travelling  across  the  bridge  flowing  smoothly  in  one  direction  or  the  other  as 
appropriate. 
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Figure  27.  Depiction  of  One-Lane  Bridge 


The  requirements  model  for  the  one-lane  bridge  appears  in  Appendix  A  as  a  set 
of  rules  that  governs  the  software  system  controlling  the  bridge.  Since  this  behavioral 
model  is  somewhat  difficult  to  comprehend  as  a  set  of  rules,  a  graphical  representation 
of  the  one-lane  bridge  control  system  is  provided  in  Appendix  B. 
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B.  ONE-LANE  BRIDGE  HAZARD 


For  the  purpose  of  presenting  an  application  of  the  decomposition  templates,  the 
one-lane  bridge  control  system  is  analyzed  for  the  hazard  "Two  Cars  Simultaneously  on 
Bridge  in  Opposite  Directions".  Normally,  the  event  at  the  root  of  a  fault  tree  would 
be  much  more  specific  than  this  event,  but  for  the  purposes  of  illustration  an  event  of 
this  generality  is  used  so  as  to  demonstrate  the  various  applications  of  the 
decomposition  templates  developed  in  Chapter  n.  The  event  "Two  Cars 
Simultaneously  on  Bridge  in  Opposite  Directions"  is  used  as  a  starting  point  because  it 
is  an  event  that  is  unsafe  for  the  motorists  travelling  across  the  bridge,  and  is  an  event 
that  the  software  control  system  should  not  allow  to  occur.  This  hazard  appears  at  the 
root  of  the  resultant  software  fault  tree,  and  is  the  initial  event  decomposed  via  the 
decomposition  templates.  It  is  noted  that  the  decomposition  process  is  not  concerned 
with  whether  the  hazard  could  occur  for  reasons  beyond  the  control  of  the  software, 
such  as  cars  ignoring  a  red  light  and  illegally  entering  the  bridge. 

C.  DECOMPOSITION  OF  ONE-LANE  BRIDGE  HAZARD 
1.  Specificity-of-Event  Decomposition  Dimension 

The  Specificity  of  Event  decomposition  dimension  is  used  to  make  the 
hazard  event,  "Two  Cars  Simultaneously  on  Bridge  in  Opposite  Directions",  more 
specific  in  terms  of  events  and  conditions  associated  with  these  events.  Inspection  of 
the  hazard  indicates  that  one  way  in  which  the  hazard  event  could  be  decomposed  is  by 
using  the  AND  (WHILE/WHEN)  template  (Figure  28). 

The  AND  (WHILE/WHEN)  template  is  indicated  because  the  hazard  requires  that 
an  event  occurs  while  a  condition  holds.  The  event  is  "Lights  in  Both  Directions 
Green  Simultaneously".  The  condition  associated  with  this  event  is  that  "Two  Cars 
Approach  From  Opposite  Directions".  All  subsequent  decompositions  under  the  event 
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side  of  the  AND  (WHILE/WHEN)  template  branch  occur  within  the  scope  of  this 
condition. 


Two  Cars  Smullamously  On 
Bridge  m  Opposite  Orections 


Figure  28.  Bridge  Hazard  Decomposition 


The  decomposition  of  the  event  side  of  Figure  28  makes  further  use  of  the 


Specificity  of  Event  decomposition  dimension  and  is  based  upon  the  analyst’s 
knowledge  of  the  system.  Inspection  of  the  requirements  model  in  Appendix  B  reveals 
that  there  are  four  separate  system  controlled  events  that  could  cause  the  event  side  of 
Figure  28,  "Lights  in  Both  Directions  Green  Simultaneously",  to  occur.  Since  these 
four  events  are  independent  of  one  another,  they  are  decomposed  from  the  event  side  of 
Figure  28  through  the  use  of  the  OR  template  (Figure  29).  Each  of  these  four  events 
are  analyzed  independently  by  the  fault  tree  because  any  one  alone  could  cause  the 
event  side  of  Figure  28  to  contribute  to  the  occurrence  of  the  hazard. 


The  events  decomposed  by  Figure  29  come  from  the  requirements  model  for 


the  one-lane  bridge  (Appendix  B).  The  analyst  must  determine  the  ways  in  which  the 
event  "Lights  in  Both  Directions  Green  Simultaneously"  from  Figure  28  could  occur 
within  the  scope  of  the  system’s  control.  The  requirements  model’s  "Initialization" 
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Figure  29.  Decomposition  of  Bridge  Hazard  Event 


process  and  two  light  control  processes  indicate  that  the  "Lights  in  Both  Directions 
Green  Simultaneously"  event  could  occur  by  at  least  four  events  that  are  controllable 
by  the  system’s  software. 

The  first  event  is  "Lights  Not  Initialized  Red".  If  the  lights  are  not 
initialized  red,  then  the  possibility  exists  for  the  lights  to  initially  come  on  green  when 
the  system  starts  to  control  the  bridge. 

The  second  and  third  events  consider  the  cases  where  one  light  is 
commanded  to  green  while  the  other  light  already  green.  These  two  events  are 
essentially  the  same  event  with  the  difference  being  which  light  is  already  green,  and 
which  light  is  being  commanded  to  green  by  the  software.  Due  to  this  reflexive 
condition,  only  the  event  "Right-Bound  Light  Commanded  Green  While  Left-Bound 
Light  Green"  will  be  expanded.  The  conditional  nature  of  this  event  indicates  that  the 
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event  "Right-Bound  Light  Commanded  Green  While  Left-Bound  Light  Green"  can  be 
further  decomposed  using  the  AND  (WHILE/WHEN)  template. 

The  fourth  event  considered  that  is  controllable  by  the  system  software  is 
"Software  Commands  Both  Lights  Green  Simultaneously".  This  event  delves  into 
whether  or  not  the  system  is  capable  of  turning  the  traffic  lights  in  both  directions 
green  at  the  same  time. 

As  shown  in  Figure  29,  the  event  "Right-Bound  Light  Commanded  Green 
While  Left-Bound  Light  Green"  is  decomposed  into  the  event  "Right-Bound  Light 
Commanded  Green"  and  the  condition  "Left-Bound  Light  Green"  through  the 
application  use  of  another  AND  (WHILE/WHEN)  template.  This  decomposition  step  is 
necessary  to  distinguish  the  event  being  considered  for  further  decomposition  by  the 
fault  tree  from  the  condition  whose  scope  will  cover  all  subsequent  decompositions  of 
the  associated  event. 

Cases  such  as  one  or  both  lights  being  stuck  in  the  green  position  are 
hardware  related  and  are  not  considered  by  this  particular  fault  tree  application.  The 
analyst  may  elect  to  include  hardware  events  as  a  means  of  branching  into  hardware 
fault  tree  analysis  in  a  manner  similar  to  that  presented  by  Leveson  [Ref.  5:p.  570].  If 
this  were  the  case,  then  the  inclusion  of  hardware  controlled  events  such  as  lights  being 
stuck  green  would  be  appropriate  in  this  decomposition  step. 

2.  Subsystem-Size  Decomposition  Dimension 

Up  until  this  point,  the  decomposition  process  has  used  the  Specificity-of- 
Event  decomposition  dimension  for  decomposing  the  hazard.  Further  decomposition  of 
the  event  branches  of  Figure  29  with  regard  to  the  Specificity-of-Event  dimension  do 
not  readily  follow,  suggesting  that  the  Subsystem-Size  decomposition  dimension  should 
be  considered.  To  illustrate  the  Subsystem-Size  decomposition  dimension,  the  event 
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branches  of  Figure  29  are  further  decomposed  using  Subsystem  decomposition 
templates. 

The  Subsystem  template  allows  the  current  subsystem  to  be  broken  down 
into  subsystems  of  smaller  scope  that  are  more  directly  applicable  to  the  occurrence  of 
the  hazard.  These  decomposition  steps  are  driven  by  the  events  that  are  being 
decomposed  and  start  with  the  entire  system  being  considered  as  the  root  of  the 
Subsystem  template.  Each  event  from  the  branches  of  Figure  29  decomposes  in  this 
case  the  entire  system  into  the  subsystem  that  plays  a  role  in  each  particular  events 
occurrence. 

The  event  "Lights  Not  Initialized  Red"  from  Figure  29  indicates  that  the 
further  decomposition  of  this  event  requires  the  system  to  be  broken  down  into  the 
subsystem  that  controls  the  initialization  of  the  lights,  in  this  case  the  "Initialize 
System"  process  (Figure  30).  This  decomposition  step  makes  use  of  the  process  branch 
of  the  Subsystem  template,  indicating  that  it  is  the  input-process-output  of  the 
"Initialize  System"  process  that  should  be  next  analyzed  to  determine  whether  the  lights 
are  initialized  red  by  the  system.  Neither  the  Communication  branch  nor  the  Access 
branch  of  the  Subsystem  Template  are  indicated  as  avenues  for  further  decomposition 
because  the  requirements  model  in  Appendix  A  presents  "Initialize  System"  as  a 
process  that  does  not  communicate  with  other  processes  and  does  not  have  access  to 
any  device  or  database.  Therefore,  the  Communication  and  Access  branches  are  both 
represented  by  a  diamond  indicating  that  there  is  no  further  decomposition  along  these 
avenues. 

The  application  of  the  Process  template  to  the  process  branch  of  Figure  30 
is  represented  by  Figure  31.  The  process  "Initialize  System"  is  decomposed  with 
regard  to  the  event  "Lights  Not  Initialized  Red"  carried  through  from  the  subsystem 
decomposition  in  Figure  30.  The  Process  template  gives  a  structure  for  analyzing  the 
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Figure  30.  Process  Subsystem  Decomposition 


process  contained  within  "Initialize  System".  Figure  31  shows  that  the  input  to  the 
process,  the  output  from  the  process,  and  the  constructs  internal  to  the  process  must  all 
be  analyzed  to  determine  if  one  or  more  of  these  parts  of  the  "Initialize  System" 
process  could  allow  the  "Lights  Not  Initialized  Red"  event  to  occur. 

The  event  "Right-Bound  Light  Commanded  Green"  from  Figure  29  indicates 
that  the  access  that  the  system  has  to  the  right-bound  light  should  be  checked  for  this 
event.  By  analyzing  the  graphical  representation  of  the  one-lane  bridge  requirements 
model  in  Appendix  B,  it  is  apparent  that  the  part  of  the  system  that  has  access  to  the 
right-bound  light  is  the  "Control  RB  Light"  process.  Figure  32  indicates  that  the  access 
of  the  "Control  RB  Light"  process  to  the  right-bound  light  should  next  be  analyzed  to 
determine  whether  the  right-bound  light  can  be  commanded  green  while  the  condition 
of  the  left-bound  light  already  being  green  holds.  Neither  the  Process  branch  nor  the 
Communication  branch  of  the  Subsystem  template  are  indicated  for  further 
decomposition,  so  both  of  these  branches  are  represented  as  diamonds  in  Figure  32. 
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Figure  31.  Process  Template 


Decompose  Entire  Bridge  Control 
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Figure  32.  Access  Subsystem  Decomposition 


47 


The  application  of  the  Access  template  to  the  access  branch  Figure  32  is 
represented  by  Figure  33.  The  process  "Control  RB  Light"  is  decomposed  with  regard 
to  the  event  "Right-Bound  Light  Commanded  Green"  carried  through  from  the 
subsystem  decomposition  in  Figure  32.  The  Access  template  gives  a  structure  for 
analyzing  the  access  that  the  process  "Control  RB  Light"  has  to  the  right-bound  light  of 
the  one-lane  bridge. 


Figure  33.  Access  Template 


The  template  in  Figure  33  shows  the  three  cases  that  must  hold,  and 
therefore  be  analyzed  by  the  fault  tree,  in  order  for  the  "Control  RB  Light"  process  to 
cause  the  event  "Right-Bound  Light  Commanded  Green".  The  first  case  is  that 
"Control  RB  Light"  must  have  access  to  the  Right-Bound  light  on  the  bridge.  The 
second  case  is  that  "Control  RB  Light"  must  be  capable  of  sending  one  or  more 
commands  to  the  Right-Bound  light  that  would  result  in  the  event  "Right-Bound  Light 
Commanded  Green".  The  third  case  is  that  "Control  RB  Light"  must  actually  send  the 
commands  specified  in  the  second  case  to  the  Right-Bound  light. 
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The  decomposition  of  the  event  "Software  Commands  Both  Lights  Green 
Simultaneously"  from  Figure  29  requires  knowledge  of  how  the  system  allows  each 
light  to  be  commanded  green.  Requirements  model  rules  1  and  5  from  the 
requirements  model  in  Appendix  A  require  each  light  control  process  to  wait  until 
exclusive  access  to  the  bridge  is  granted  before  turning  the  controlled  light  green.  This 
requirement  of  waiting  for  exclusive  access  indicates  that  the  system  should  be  broken 
down  into  the  subsystems  that  communicate  through  whatever  process  controls  the 
exclusive  access  to  the  bridge  (Figure  34). 


Figure  34.  Communication  Subsystem  Decomposition 


The  requirements  model  identifies  two  processes  that  control  the  access  to 
the  bridge  through  a  rendezvous  type  operation.  These  two  processes  are  the  "RB  Wait 
For  Exclusive  Access  To  Bridge"  process  and  the  "LB  Wait  For  Exclusive  Access  To 
Bridge"  process.  For  illustration  purposes  these  two  processes  will  be  referred  to  as 
"RB  Exclusive  Access"  and  "LB  Exclusive  Access"  respectively.  The  application  of 
the  Communication  template  to  the  Communication  branch  of  Figure  34  is  represented 
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by  Figure  35.  The  two  processes,  "RB  Exclusive  Access"  and  "LB  Exclusive  Access", 
that  control  the  access  to  the  bridge  through  a  rendezvous  type  operation  are 
decomposed  with  regard  to  the  event  "Software  Commands  Both  Lights  Green 
Simultaneously"  carried  through  from  the  subsystem  decomposition  in  Figure  34.  The 
Communication  template  gives  a  structure  for  analyzing  the  rendezvous  type  operation 
which  is  the  way  the  two  exclusive  access  processes  are  assumed  to  communicate.  At 
this  point,  neither  the  Process  branch  nor  the  Access  branch  of  the  Subsystem  template 
are  indicated  for  further  decomposition.  These  branches  are  therefore  both  represented 
by  diamonds  in  Figure  34. 


Figure  35.  Communication  Template 


As  Figure  35  indicates,  the  rendezvous  between  the  two  exclusive  access 
processes  must  be  evaluated.  The  effect  of  a  rendezvous  is  to  create  a  new  process. 
This  new  process  is  entirely  made  up  of  the  interaction  that  goes  on  between  the  two 
exclusive  access  processes  when  the  rendezvous  type  operation  is  accomplished,  and  is 
in  fact  the  single  process  that  actually  controls  exclusive  access  to  the  bridge.  This 
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new  process  must  be  analyzed  to  determine  if  it  could  cause  the  event  "Software 
Commands  Both  Lights  Green  Simultaneously".  The  next  step  of  the  analysis,  as 
indicated  by  the  Communication  template,  is  to  analyze  the  new  process  using  a 
Process  Template.  Based  upon  the  assumption  that  the  two  exclusive  access  processes 
communicate  via  a  rendezvous  type  operation,  the  Communication  via  Shared  Memory 
and  Communication  via  Exchange  of  Data  branches  of  the  Communication  template  are 
not  pursued.  These  two  branches  are  therefore  each  represented  by  a  diamond  in  the 
Communication  Template  of  Figure  35. 

3.  Overall  Fault  Tree  for  Bridge  Hazard 

Figure  36  shows  the  entire  software  fault  tree  that  results  from  the 
application  of  decomposition  templates  to  the  one-lane  bridge  hazard.  The 
decomposition  process  using  the  decomposition  templates  developed  in  Chapter  II 
continues  until  the  point  at  which  the  specific  system  modules,  events  and  associated 
conditions  are  indicated  is  sufficient  detail.  At  this  point,  if  the  software  system  has 
been  developed  down  to  the  code  level,  the  software  fault  tree  analysis  can  be 
continued  through  the  application  of  Cha  statement  templates.  If  the  software  system  is 
has  not  yet  been  developed  to  the  code  level,  the  modules,  events  and  conditions 
indicated  by  the  software  fault  tree  can  be  used  to  provide  specific  input  regarding 
what  the  detailed  design  of  the  indicated  modules  should  be  concerned  with. 

D.  SUMMARY  OF  DECOMPOSITION  TEMPLATE  APPLICATION 

Hazard  decomposition  using  the  decomposition  templates  presented  in  this  thesis 
continues  until  a  contradiction  is  reached,  or  a  specific  process  within  the  software 
system  is  indicated.  Where  a  specific  process  is  indicated,  the  decomposition  of  the 
hazard  continues  with  the  use  of  statement  templates.  The  use  of  statement  templates 
is  supported  by  the  structure  of  the  fault  tree  resulting  from  the  application  of  the 
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Figure  36.  Overall  Fault  Tree  for  Bridge  Hazard 


52 


decomposition  templates.  The  fault  tree  up  to  this  point  contains  the  conditions  that 
must  hold  and  the  events  that  must  occur  in  order  for  the  system  to  arrive  in  the  unsafe 
state  of  the  hazard.  With  the  fault  tree  indicating  a  specific  process  or  subsystem,  the 
use  of  statement  templates  can  be  better  focused.  The  statement  templates  now  have 
the  advantage  of  starting  off  pointing  to  the  specific  process  to  be  analyzed,  with  both 
the  events  and  associated  conditions  known. 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  purpose  of  this  thesis  is  to  develop  a  formalized  method  of  decomposing 
system-level  hazards.  The  decomposition  templates  presented  herein  provide  the 
software  fault  tree  analyst  with  a  framework  for  decomposing  a  hazard  to  the  point  at 
which  line  by  line  code  analysis  can  be  conducted  with  existing  statement  templates. 
This  framework  serves  as  a  formal  method  for  conducting  the  decomposition  of  system- 
level  hazards,  and  ensures  that  as  many  as  possible  of  the  applicable  decomposition 
aspects  are  considered.  The  decomposition  of  system-level  hazards  had  previously  been 
conducted  in  a  largely  human  intensive  manner,  carrying  both  the  drawback  of 
introducing  human  error  in  the  form  of  oversight  as  well  as  the  strength  of  human 
insight.  The  application  of  the  decomposition  templates  developed  in  this  thesis  serves 
to  reduce  the  former  and  enhance  the  later. 

1.  Relevance  to  MIL-STD-882B 

Task  202  of  MIL-STD-882B  [Ref.  ll:p.  202-1]  provides  guidelines  for  the 
identification  of  safety  critical  areas  and  the  evaluation  of  hazards.  The  hazards 
identified  here  include  the  potential  contribution  of  software  events  to  system/subsystem 
mishaps.  These  software  events  include  software  commands  and  responses  such  as 
inadvertent  commands,  failure  to  command,  and  untimely  commands  and  responses. 
The  decomposition  templates  developed  within  the  Specificity-of-Event  Decomposition 
Dimension  of  Chapter  II  can  be  used  to  determine  the  software  events  that  can 
contribute  to  system  mishaps.  The  events  identified  by  the  decomposition  templates 
can  then  be  incorporated  into  the  safety  design  criteria  of  the  software  specifications. 
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Task  203  of  MIL-STD-882B  [Ref.  ll:p.  203-1]  provides  guidelines  for  the 
identification  of  hazards  associated  with  the  design  of  subsystems.  The  hazards 
identified  here  include  the  potential  contribution  of  software  events  and  faults  with 
regard  to  the  safety  of  a  subsystem.  The  subsystem  decomposition  templates  developed 
within  the  Subsystem-Size  Decomposition  Dimension  of  Chapter  II  can  serve  as  an 
analysis  technique  for  performing  Task  203’s  Subsystem  Hazard  Analysis  with  regard  to 
the  software  of  a  system,  and  can  be  used  to  determine  whether  the  safety  design 
criteria  in  the  software  specification  have  been  satisfied. 

2.  Advantages  of  Decomposition  Templates 

The  advantages  of  using  the  decomposition  templates  presented  in  this  thesis 
to  decompose  system-level  hazards  stem  from  the  formalized  standpoint  from  which  the 
templates  were  developed.  The  decomposition  templates  give  the  software  fault  tree 
analyst  a  structured  viewpoint  from  which  to  evaluate  the  software  system.  The  fault 
tree  analyst  can  shift  between  the  two  interdependent  decomposition  dimensions  as 
necessary,  focusing  on  either  increasing  the  specificity  of  the  event  being  considered,  or 
reducing  the  scope  of  the  subsystem  associated  with  the  event.  Shifting  from  one 
decomposition  dimension  to  another  essentially  allows  the  decomposition  process  to 
shift  the  perspective  from  which  the  software  system  is  being  considered.  The 
templates  serve  to  aid  the  analyst  by  providing  a  step  by  step  framework  with  which  to 
approach  each  subsequent  decomposition  of  the  system-level  hazard.  As  indicated  in 
Chapter  III,  this  decomposition  process  can  be  continued  until  the  point  at  which 
statement  templates  can  be  used.  The  structure  of  the  software  fault  tree  provides  the 
analyst  with  information  that  focuses  the  application  of  statement  templates.  The 
application  of  statement  templates  yields  information  of  sufficient  detail  so  as  to  allow 
the  analyst  to  make  use  of  the  Ada  exception  handling  mechanism  as  a  method  of 
pruning  the  developing  fault  tree.  Pruning  a  fault  tree  in  this  manner  is  analogous  to 
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Leveson  and  Harvey’s  method  of  inserting  run-time  checks  into  the  code  to  trap  a 
developing  unsafe  state  [Ref.  4:p.  576].  Each  decomposition  step  provides  specific 
events  and/or  conditions  that  are  to  be  further  evaluated,  as  well  as  the  specific 
subsystem  within  which  to  evaluate  these  events  and  conditions.  Applying  the 
decomposition  templates  presented  in  this  thesis  effectively  yields  pointers  to  specific 
modules  within  the  overall  software  system,  along  with  information  such  as  events  and 
conditions  that  the  module  needs  to  be  evaluated  for.  The  effect  of  the  use  of  hazard 
decomposition  templates  is  to  give  the  application  of  statement  templates  a  specific 
starting  point,  as  well  as  a  specific  hazard  to  be  analyzed  by  the  statement  templates. 

3.  Limitations  of  Decomposition  Templates 

The  application  of  decomposition  templates  does  not  relieve  the  analyst  from 
the  need  for  a  through  understanding  of  the  software  system.  In  order  for  the 
Subsystem-Size  Decomposition  Dimension  to  be  effective,  the  analyst  must  be 
thoroughly  familiar  with  the  communication  links  and  interfaces  through  which  the 
software  system  will  function.  The  reliance  of  this  decomposition  dimension  on  the 
communication  between  modules  implies  that,  at  a  minimum,  a  high-level  design  of  the 
software  system  to  be  analyzed  is  needed  in  order  for  this  decomposition  dimension  to 
be  effective.  This  requirement  obviously  limits  the  effectiveness  of  this  dimension  if 
application  when  applied  to  solely  the  requirements  specification  of  a  system. 

The  effectiveness  of  the  Specificity-of-Event  Decomposition  Dimension  is 
also  reliant  on  the  analyst’s  knowledge  of  the  software  system.  The  focus  of  this 
decomposition  dimension  centers  around  itemizing  each  event  that  could  cause  the 
given  hazard  in  the  current  subsystem.  For  the  fault  tree  to  fully  reflect  all  the  possible 
paths  in  which  the  hazard  could  occur,  the  scope  of  the  decomposition  must  constitute 
a  complete  enumeration  of  the  ways  in  which  the  hazard  could  occur  within  the  current 
subsystem.  In  other  words,  the  events  resulting  from  any  decomposition  step  must 
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represent  in  total  the  ways  in  which  the  hazard  could  occur  at  that  level.  A  problem 
arises  in  how  confident  the  analyst  is  that  every  resultant  event  has  been  properly 
reflected  in  the  decomposition.  Specifically,  the  analyst  must  know  when  every  event 
that  could  result  from  the  decomposition  of  the  hazard  within  the  current  subsystem  has 
been  considered.  For  the  Specificity-of-Event  Decomposition  Dimension  to  be 
effective,  it  is  clear  that  a  through  knowledge  of  how  the  software  system  functions  is 
required. 

B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

Several  topics  related  to  this  thesis  warrant  further  research.  First,  research  is 
needed  to  determine  how  the  process  of  decomposing  a  system-level  hazard  can  be 
automated.  Even  with  the  software  fault  tree  limited  to  the  analysis  of  safety  critical 
events,  the  fault  tree  of  a  moderately  sized  system  will  be  substantial.  Although  aided 
by  the  decomposition  template  framework,  the  development  of  any  fault  tree  is  labor 
intensive.  The  reliance  of  the  Subsystem-Size  Decomposition  Dimension  on  the 
communication  links  and  interfaces  of  a  system  suggests  that,  given  a  high-level  design, 
automation  of  this  decomposition  dimension  may  be  possible. 

Second,  the  issue  of  integrating  formal  requirements  into  a  safety  analysis  should 
be  investigated.  The  ability  of  the  Specificity-of-Event  Decomposition  Dimension  to  be 
applied  to  the  requirements  of  a  system  indicates  that  this  decomposition  dimension  can 
be  an  effective  method  of  analyzing  the  requirements  of  a  system  from  a  safety 
standpoint. 

A  third  area  recommended  for  research  is  the  possibility  of  transferring  the 
logical  basis  of  the  templates  into  a  formal  logic.  A  formal  logic  would  enable  the 
analyst  to  give  proof  conditions  that  could  be  used  to  formally  prove  whether  the 
system  could  arrive  in  a  state  in  which  a  specific  hazard  has  occurred. 
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APPENDIX  A.  REQUIREMENTS  MODEL  RULES  FOR  ONE-LANE  BRIDGE 


Rule  1  : 

Rule  2  : 

Rule  3  : 

Rule  4  : 

Rule  5  : 

Rule  6  : 

Rule  7  : 

Rule  8  : 


If  in  right-bound  state  Traffic.Idle  and  a  right-bound  car  approaches  the 
bridge  (as  detected  by  sensor  1),  then  set  RB_Cars  to  1,  request 
Access.to.Bridge,  and  enter  right-bound  state  Wait_for_Exclusive_Access 
to_Bridge.  When  exclusive  access  is  granted,  enter  right-bound  state 
Traffic. Active  and  turn  light  RB  green. 

If  in  right-bound  state  Traffic.Active  and  a  right-bound  car  leaves  the  bridge 
(as  detected  by  sensor  2)  and  RB.Cars  is  not  1,  then  decrement  RB.Cars  by 
1. 

If  in  right-bound  state  Traffic.Active  and  a  right-bound  car  leaves  the  bridge 
(as  detected  by  sensor  2)  and  RB.Cars  is  not  1,  then  decrement  RB.Cars 
by  1. 

If  in  right-bound  state  Traffic.Active  and  a  right-bound  car  leaves  the  bridge 
and  RB.Cars  is  1,  then  turn  light  RB  red,  set  RB.Cars  to  0,  release 
Access_to_Bridge,  and  enter  right-bound  state  Traffic.Idle. 

If  in  left-bound  state  Traffic.Idle  and  a  left-bound  car  approaches  the  bridge 
(as  detected  by  sensor  3),  then  set  LB  .Cars  to  1,  request  Access_to_B  ridge, 
and  enter  left-bound  state  Wait_for_Exclusive_Access_to_Bridge.  When 
exclusive  access  is  granted,  enter  left-bound  state  Traffic. Active  and  turn 
light  LB  green. 

If  in  right-bound  state  Traffic.Active  and  a  right-bound  car  leaves  the  bridge 
(as  detected  by  sensor  2)  and  RB.Cars  is  not  1,  then  decrement  RB.Cars  by 
1. 

If  in  left-bound  state  Traffic.Active  and  a  left-bound  car  leaves  the  bridge 
(as  detected  by  sensor  4)  and  LB.Cars  is  not  1,  then  decrement  LB.Cars 
by  1. 

If  in  left-bound  state  Traffic.Active  and  a  left-bound  car  leaves  the  bridge 
and  LB.Cars  is  1,  then  turn  light  LB  red,  set  LB.Cars  to  0,  release 
Access.to.Bridge,  and  enter  left-bound  state  Traffic.Idle. 
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APPENDIX  B.  GRAPHICAL  REPRESENTATION  OF  ONE-LANE  BRIDGE 


Set  Light  RB  Red  * —  Initialize  System  —  ►  Set  Light  LB  Red 


Right-Bound  Car  Righi-Bound 

Approaching  Car  Leaving 


lxrft-Bound  Car 
Approaching 


▼ 


Ixft-Bound 
Car  leaving 


▼ 


Control  Kit  light  -  -  Control  lit  light 

|l:igurc  3-2|  -  -  (Figure  3-3| 


Set  light  Set  light 

Kit  Red  Kit  Green 


▼  V 

Set  Light  Set  Light 

LB  Red  LB  Green 


Acccss_to_Brtdgc  (Semaphore) 

RB_Cars,  LB  Cars  (Nonnegative  Integer) 

FIGURE  3-1:  Graphical  Representation  of  Behavioral  Requirements: 
Control  Transformations 
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Uglit  KB,  LB  =  Red 

Access.to.Bridge  =  l?rcc  i -  —  —  —  [Figure  3-3] 

KB.Cars,  LB.Cars  =  0 

T 


* 


♦ 


♦ 

♦ 


KLght-Bound.Trarnc.ldlc  * 

* 


******************************************* 

Car  Approaches  on  lx:ft  * 


KB.Cars  =  1 

Request  Access.to.Bridge 


* 


* 


* 


KB.Wait_for.Iixclusivc.Access.to.lh  idge 


Granted  Access.to.Bridge 
Uglit  KB  =  Green 


Car  Approaches  on  lx;  ft 
KB.Cars  =  KB.Cars  +  1 


Right-Bound.' Traffic.Active 


Car  Leaves  Right 
and  KB.Cars  =  1 


Light  KB  =  Red 
Access.to.Bridge  = 
Tree 

KB.Cars  «  0 


* 

* 

* 


A  A 


Car  Approaches  on  Left 


Car  Leaves  Right  and  KB.Cars  >  1 


KB.Cars  =  KB.Cars  +  1 


KB.Cars  =  KB.Cars  -  1 


FIGURE  3-2:  Graphical  Represenlallon  of  Behavioral  Requirements: 
Slale  Translllon  Diagrams 
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|  Figure  3-2 1 


▼ 


*  Left- Bound.TrafficJ  die  * 

*  * 


Car  Approaches  on  Right 


A 


LB.Cars  =  1 

Request  Acccss.to.Bridgc 


LB.Wait.for.Lxciusive.Access.toBridge 


Granted  Acccss.to.Bridgc 
Light  LB  =  Green 


Car  Approaches  on  Right 
LB.Cars  =  LHCars  +  1 


Car  Leaves  Left 
and  LB.Cars  =  1 


light  LB  =  Red 
Acccss.to.Bridgc  = 
Tree 

LB.Cars  =  0 


Left-Bound  Traffic.Active 


Car  Approaches  on  Right  Car  leaves  Left  and  LB  Cars  >  1 

LB.Cars  =  LB.Cars  +  1  LB.Cars  =  LB  Cars  -  1 


FIGURE  3*3:  Graphical  Representation  of  Behavioral  Requirements: 
Slate  Transition  Diagrams 
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